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(57) ABSTRACT 

A system and method for summarizing metric data in a 
semantically correct way. The system preferably comprises 
a distributed computing environment, i.e., an enterprise, 
which comprises a plurality of interconnected computer 
systems. At least one of the computer systems is an agent 
computer system which collects raw data relating to one or 
more metrics, i.e., measurements of system resources on the 
agent computer system. A Universal Data Repository 
(UEDR) receives a set of data points representing metric 
data from one or more agent computer systems. The UDR 
summarizes the set of data points into a more compact yet 
meaningful form. In summarization, the UDR determines a 
data type of the set of data points, applies a summarization 
rule according to the data type, and then creates a summa- 
rized data structure which corresponds to the set of data 
points. The summarization rule varies according to the 
semantics of the data type. The UDR can summarize both 
raw data and data that has previously been summarized one 
or more times. So that the record of a particular process is 
never totally lost, process state changes are preserved 
throughout. 

61 Claims, 17 Drawing Sheets 



An Enterprise Computing Environment 

GD 




02/13/2004, EAST Version: 1.4.1 




02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 2 of 17 US 6,560,647 Bl 




02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 3 of 17 



US 6,560,647 Bl 



5 

o 

o 
> 

O 




CO 

ej 

Ll_ 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 4 of 17 US 6,560,647 Bl 




6 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 5 of 17 US 6,560,647 Bl 




02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 6 of 17 



US 6,560,647 Bl 



x. 



CO 

CO| 
O CM 



fXZ 



CO 



I 



A 



o> Eco 



> 
O 

N 
>» 

(0 

c 

< 





CO 



CD J!> ^ 
<CD— - 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 7 of 17 



US 6,560,647 Bl 



CP 
> 

O 



I. 



CO 

d CO 

O CD 

CO CO 
O c O 
P CD'C 

4J fcr (O 

CD ^ CO -C 
— ' 3 CO O 

o o 
o 



AT 



82 



CD 



4= 

o Eg 



. J 



A 



A 



CD 
h_ 

c: co^r 
co a> 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 8 of 17 



US 6,560,647 Bl 



CO 




CD 
oo 

O 

LL 



c .c -a *o 
« 0 a> 2 M 

Q_ CD _^ CD 



CO 



CO 




type 




CO 




mine dai 
of data 


SI 

col 






Del 






< 

oo 
CD 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 9 of 17 



US 6,560,647 Bl 



Start J 



3 



Collect new sample at 
specified collection rate 
650 



Write new sample to Metric Repository 
652 



Cache new sample in 
Metric Repository Pool 
654 



Place new sample into queue 
656 




Has 

'summarization" 
.interval expired'? 
658 

Yes" 



Summarize all queued samples and write 
summarized structure to summarized file 

660 

i 



Clear queue and reset 
summarization interval 
662 




Flush unsummarized samples to 
summarized file 
668 



Transfer summarized file to 

requesting node 
§ZQ 



FIG. 9 



02/13/2004, EAST Version: 1.4.1 



. Patent May 6, 2003 Sheet 10 of 17 US 6,560,647 Bl 



Start 



Collect new sample at 
specified collection rate 
702 



i - — 

Write new sample to Metric Repository 

704 

Cache new sample in 
Metric Repository Pool 
706 





Goto A (raw-file, new sample) 
Z08 







FIG. 10A 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 11 of 17 US 6,560,647 Bl 



(A (File, Sample)) 




Summarize oldest M FilB 
samples from File into 
coarser-sample 
724 



I 



Goto A (next-coarser- 
file, coarser-sample) 
726 



Remove oldest M File 
samples from File 
728 




FIG. 10B 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 12 of 17 



US 6,560,647 Bl 




02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 13 of 17 US 6,560,647 Bl 



c 
o 

V-* 

CO 
N 
'l. 
CO 

E 
E 

CO 

CO 

"co 
Q 

q 

Z> 



E 

"I— 

c 

CO 

a? 

o 



CD 



CD 



_CD 



CD Q. 

5 Eg 

Q> CO* 

zco 



-I 

LOl 
CD 



0) 
CD 

a: 
i2 
Q 

± 



1° 

J?oo 



CD 

E 
i — 

ca 

CD 



a> 



-St' 



O— CO 
CO 



. CM 

O 
4t 



0) 

Q_ cm 

E J 

CO ^ 
CO 



m Ql w 

I E I 

CD CO* 
ZCO 



To 
a: 
eg 

CO 

Q 



co -o 
■gig 

CO 



CD 

E 
i— 
o> 

*C/5 
CO 
CD 

O 



jd 

cl <r> 

E J 
co =tt 

CO 



CD I* 
ZCO 



ml 

CD 



CO 

a; 

03 

"co 
Q 

§ 



CM 

CD 



O 

CO "O 



CO 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent 



May 6, 2003 



Sheet 14 of 17 



US 6,560,647 Bl 



5 
d) 

E 

© 

> 
O 

Q 
3 



0) 


















Dde 



























CD 
O 

cz 
CO 



Ci 



8 

CO 
00 

c 





CD 

£Z CO 



















CD 

m Si 



S CD 
c co~ 



_S2 o> 
So 



CO 

o 



: o) co 
X^ 



B CD 

O * co 



CD _CD 



MG#1 
High Rate 
Data File 




MG#1 
Med. Rate 
Data File 




MG#1 
Low Rate 
Data File 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 15 of 17 US 6,560,647 Bl 




02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 16 of 17 US 6,560,647 Bl 



X 

co 



Q 

CO 



CM 

Q 

CO 



a: 
Q 

CO 



CM 

o 



\ 



c 
o 

'o. 
•c 
o 
to 
© 

£ 

o 
5 
CO 



8 
? 

CD — 
M 

CO 

E 
E 

ZJ 
CO 





















c 


> 


Spills 


o 




eo 


c 
* 


> 
> 


derR 

Metric 




'o 


1— 
CD 




ea 


"O 
CO 




X 


(D 






X 








t 











c/> 

CD 
"O 
CO 
CD 

X 

8 

D_ 

E 
E 

CO 

o 



c: 

o 
o 
a. 
E 

E 
n 
c£ 

Q 



O 

\ 



o 
o 

CD CO 
IM — ' 

CO 

E 



CO 



CD 

o 



o 
o 

CD 

ct: 



CO 



CD 

§ 

■a 

o 
o 

CD 

a: 
aj 
aj 
Q 



CD 

o 
■s 
8 

<D 
01 
&— 
CD 
"O 
CO 
CD 



O 



CD 
■o . 
CO 
CD 

X 



CD 



8 3 

CO 



LO 



£2 

CD 
"O 
CO 
CD 



O 
O 
Q_ 

E 
E 

CO 
6 







CNI 






SHF 


SDR 


SDR 




SDR 







CM 






tfHS 


SDR 


SDR 




SDR 



X 




CM 




z 


C£ 


a: 




a: 


CO 


Q 


Q 




Q 


CO 


CO 




CO 



CM 



a. 

CO 



CO 



CO 



02/13/2004, EAST Version: 1.4.1 



U.S. Patent May 6, 2003 Sheet 17 of 17 US 6,560,647 Bl 



en 
x 

CO 



a: 



CM 
CO 



o 

CO 




J2 
o 
■o 

CO 
CD 



c 

o 
o 

CL 



£3 



a: 



2) 



Q 



a: 



CM 

Q 



1 



CM 



CM 



CO 



Q. 
CO 



Q. 
CO 



02/13/2004, EAST Version: 1.4.1 



US 6,; 

1 

ENTERPRISE MANAGEMENT SYSTEM AND 
METHOD WHICH INCLUDES 
SEMANTICALLY CORRECT 
SUMMARIZATION 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The following are related applications to the present 
application. 

U.S. patent application Ser. No. 09/262,194 titled "Enter- 
prise Management System and Method Which Includes 
Summarization Having a Plurality of Levels of Varying 
Granularity" and filed Mar. 4, 1999. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the collection, analysis, 
and management of system resource data in distributed or 
enterprise computer systems, and particularly to a system 
and method for reducing file sizes in an intelligent way. 

2. Description of the Related Art 

The data processing resources of -business organizations 
are increasingly taking the form of a distributed computing 
environment in which data and processing are dispersed 
over a network comprising many interconnected, 
heterogeneous, geographically remote computers. Such a 
computing environment is commonly referred to as an 
enterprise computing environment, or simply an enterprise. 
Managers of the enterprise often employ software packages 
known as enterprise management systems to monitor, 
analyze, and manage the resources of the enterprise. Enter- 
prise management systems may provide for the collection of 
measurements, or metrics, concerning the resources of indi- 
vidual systems. For example, an enterprise management 
system might include a software agent on an individual 
computer system for the monitoring of particular resources 
such as CPU usage or disk access. The enterprise manage- 
ment agent might periodically collect metric data and write 
to a "data spill" containing historical metric data, i.e., metric 
data previously collected over a period of time. U.S. Pat No. 
5,655,081 discloses one example of an enterprise manage- 
ment system. 

Historical data spills can be useful in a number of cir- 
cumstances. First, even where an enterprise management 
system permits real-time monitoring of metric data, the 
enterprise is not always monitored for twenty-four hours a 
day, seven days a week. Thus, historical data spills provide 
a way to review metric data that was not monitored in real 
time. Second, regardless of whether metrics are monitored in 
real time, an enterprise manager may desire to review the 
history of one or more metrics which preceded a problem in 
another, related metric. Third, historical data spills can be 
used for analysis of the enterprise. For example, an analysis 
of the most frequent clients of a particular file server in the 
enterprise would utilize historical metric data. For these 
reasons, enterprise managers desire to keep track of as much 
historical metric data as possible. However, storage space 
and other resources are finite and not without cost. 
Therefore, the enterprise manager faces a trade-off between 
using costly storage resources on the one hand and throwing 
away meaningful metric data on the other hand. The object, 
then, is to reduce the amount of data stored while throwing 
out as little meaningful data as possible. 

The prior art has produced a variety of compression 
techniques for reducing file size. Some compression meth- 
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ods are "lossless**: they compress data by looking for 
patterns and redundancies, losing no information in the 
process. File-level and disk-level compression techniques 
for computer systems are lossless methods. Unfortunately, 

5 lossless methods typically achieve low compression rates, 
and so their usefulness is limited, especially for large, 
relatively patternless spills of metric data. Other compres- 
sion methods are "lossy": they typically achieve higher 
compression rates than lossless methods, but they lose 

10 information in the process. For example, techniques for 
compressing video and image data commonly eliminate 
pixel-to-pixel variances in color that are barely noticeable to 
the human eye. In other words, those methods determine the 
least necessary data by comparing pixels to one another, and 

is then the methods discard that data. However, techniques for 
compressing metric data cannot so rely on the deficiencies of 
human perception. Often, compression techniques of the 
prior art compress metric data by decimating it: in other 
words, by simply throwing away every Nth element of a data 

20 spill, or by keeping every Nth element of a data spill. 
Decimation methods thus use a "brute force** approach with 
the result that the meaningful and the meaningless alike are 
discarded. The methods of the prior art employ a "one size 
fits all" methodology: they treat all bits and bytes the same, 

25 no matter what meaning those bits and bytes may hold. The 
methods do not look beyond the mere logical ones and 
zeroes to appreciate the significance of the data. Therefore, 
both the lossless and the lossy compression methods of the 
prior art are inadequate to solve the enterprise manager's 

30 dilemma. 

For the foregoing reasons, there is a need for a system and 
method for reducing file sizes in an intelligent way. 

SUMMARY OF THE INVENTION 

35 The present invention is directed to a system and method 
that solve the need for intelligent summarization of data. 
Preferably, the present invention provides improved man- 
agement of collected metric data through summarization of 
data according to the semantics or meaning of the underly- 

40 ing data types, and also through summarization of data at a 
plurality of levels of varying granularity. In a preferred 
embodiment, the system and method are used in a distrib- 
uted computing environment, i.e., an enterprise. The enter- 
prise comprises a plurality of computer systems, or nodes, 

45 which are interconnected through a network. At least one of 
the computer systems is a monitor computer system from 
which a user may monitor the nodes of the enterprise. At 
least one of the computer systems is an agent computer 
system. An agent computer system includes agent software 

50 that permits the collection of data relating to one or more 
metrics, i.e., measurements of system resources on the agent 
computer system. 

In a preferred embodiment, a Universal Data Repository 
(UDR) receives a set of data points from one or more agent 

55 computer systems. The set of data points, is a series of 
metrics, i.e., measurements of one or more system resources, 
which have been gathered by data collectors on the agent 
computer systems over a period of time. The UDR prefer- 
ably summarizes the set of data points into a more compact 

60 yet meaningful form. In summarization according to one 
embodiment, the UDR determines a data type of the set of 
data points, applies a summarization rule according to the 
data type, and then creates a summarized data structure 
which corresponds to the set of data points. The UDR may 

65 summarize multiple sets of data points in succession. 

In one embodiment, the summarization rule varies 
according to the semantics, i.e., the meaning, of the data 
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type. For example, if the data type of the collected metric FIG. 3 is a block diagram illustrating an overview of the 

data is a counter, i.e., a measurement that can only go up, enterprise management system according to the preferred 

then the summarized data structure will comprise the start- embodiment of the present invention; 

ing value, ending value, and total number of data points. On FIG. 4 is a block diagram illustrating an overview of the 

the other hand, if the data type of the collected metric data 5 Monitor component of the enterprise management system 

is a gauge, i.e., a measurement that can go up or down, then according to the preferred embodiment of the present inven- 

the summarized data structure will comprise the average of tion; 

all the data points and the total number of data points. If the pi(j 5 is a block diagram illustrating an overview of the 

data type of the collected metric data is a clock, i.e., a ^mp^m Q f the enterprise management system 

measurement of elapsed time, then the summarized data 10 accord ing to tne preferred embodiment of the present inven- 

structure will comprise the starting value, the ending value, tion . 

and the frequency of the clock. If the data type of the metric block diagram illustrating an overview of the 

data is a string, i.e., a series of characters which can be ^ component of the enterprise management system 

manipulated as a ^oup, then the summarized data structure ^ £ ^ embodiment of mc t mveQ . 

will comprise the first suing. By applying different summa- 15 . 

rization rules keyed to different data types, the system and on * 

method preserve costly storage resources by taking the most FIG. 7 is a block diagram illustrating an overview of the 

meaningful information and putting it into smaller packages. Predict component of the enterprise management system 

To decrease file size even further, in one embodiment the to the P referred of *" P rescat 

system and -method also provide for multiple levels of 20 ' , 

summarization: as new metric data is received, previously FIG. 8a is a flowchart illustrating the semanUcally correct 

received data is summarized into coarser data structures, nature of summarization; 

wherein the degree of coarseness corresponds to the age of FIG. Sb is a flowchart illustrating the semantically correct 
the data. After the: metric data has been collected by an summarization rules for several representative data types; 
agent, the UE>R summarizes raw data points into summa- 25 fig 9 is a flowchart illustrating the summarization 
rized data structures. Each summarized data structure cor- method for a one-time collect request; 
responds to two or more of the raw data points. At later nGS 10a afld 10b are flowcharts illustrating the sum- 
times, as new raw data is collected, the UDR summarizes the ma rization method for historical data in a plurality of levels 
previously summarized data structures into still coarser of granularity- 
summarized data structures. Each coarser summarized data 30 ^ ^ ^ ^ ^ ^ fllustratm me interfacc 
stnicture^preferably corresponds to two or more of the ^ ^ ^ ^ R 

previously summarized data structures. The summarization .„ . . . 

of previously summarized data structures into coarser sum- FIG. 12 is a block diagram illustrating summarization 

marized data structures can be performed for any number of with three levels of granularity ; 

levels, as configured by the user. At each successive level of 35 FIG. 13 is a diagram illustrating the high-level file format 

summarization, metric data becomes coarser in granularity: of UDR; 

that is, the metric data representing a given period of time FIG. 14 is a diagram illustrating the data file format of 

becomes more summarized and takes up less space. UDR; 

In one embodiment, throughout the levels of FIG. 15 is a diagram illustrating the structure of data and 

summarization, the UDR preserves process state changes so 40 header records in UDR; 

that the record of a particular process is never totally lost. A FIG. 16 is a diagram illustrating the processing flow from 

process state change is the birth or death of a process at some Metric Repository (Agent) records to Data Repository 

point during the monitored time interval. In the preferred (UDR) records, 
embodiment, furthermore, the UDR stores each level of 

summarization in a different file. In each file, the data points 45 DETAILED DESCRIPTION OF THE 

or summarized data structures are stored sequentially in PREFERRED EMBODIMENT 

order of collection. When one file fills up, i.e., reaches its jj s p at ^ 0 5^655,081 titled "System for Monitoring and 

maximum file size as configured by the user, the UDR Managing Computer Resources and Applications Across a 

surnmarizes the oldest data points or data structures in that ^ Distributed Environment Using an Intelligent Autonomous 

file. The UDR then deletes the appropriate metric data from Agent Architecture" is hereby incorporated by reference as 

that file and pushes the newly summarized structure into the though fully and completely set forth herein, 

next coarsest file. When the coarsest file fills up, the oldest nG % mustrates m ent erprise computing environment 

metric data structures from the coarsest file are deleted. The according to OQC embodiment of the present invention. An 

user may configure the number of levels of summarization ^ cnt ^ m comprises a plurality of computer systems 

and thus the number of files in the enterprise management which m mterconnecled one or more networks, 

system and method. Although one particular embodiment is shown in FIG. 1, the 

BRIEF DESCRIPTION OF THE DRAWINGS enterprise 100 may comprise a variety of heterogeneous 

computer systems and networks which are interconnected in 

A better understanding of the present invention can be 60 a variety of ways and which run a variety of software 

obtained when the following detailed description of the applications. 

preferred embodiment is considered in conjunction with the q qg or more focal area networks (LANs) 104 may be 

following drawings, in which: included in the enterprise 100. A LAN 104 is a network that 

FIG. 1 is a network diagram of an illustrative enterprise spans a relatively small area. Typically, a LAN 104 is 

computing environment; 65 confined to a single building or group of buildings. Each 

FIG. 2 is an illustration of a typical computer system with node (i.e., individual computer system or device) on a LAN 

computer software programs; 104 preferably has its own CPU with which it executes 
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programs, and each node is also able to access data and prise 100. Each computer system 150 in the enterprise 100 

devices anywhere on the LAN 104. The LAN 104 thus executes or runs a plurality of software applications or 

allows many users to share devices (e.g., printers) as well as processes. Each software application or process consumes a 

data stored on file servers. The LAN 104 may be charac- portion of the resources of a computer system and/or net- 

terized by any of a variety of types of topology (i.e., the 5 work: for example, CPU tune system memory such as 

xenzea oy any oi a vancLy ul iyy^> y i &jr V , ram, nonvolatile memory such as a hard disk, network 

geometric arrangement of devices on the network), ot pro- r™. ' .j/T \ • w . \ rp, . .7 ma „ am . 

data, and whether the network uses ? « ^ Z Jrl^urce uT g e on heterogeneous coriputer^stems 

server architecture), and of media (e.g., twisted-pair wire, is„ „„'~ii, * . inft 

coaxial cables, fiber optic cables, radio waves). As illus- 10 150 ' he eaterpnse 100 , , . 
trated in FIG 1, the enterprise 100 includes one LAN 104. FIG. 3 shows an overview of the enterpnse management 

However, in alternate embodiments the enterprise 100 may system 180. The enterpnse managemen system 180 

toclude a plurality of LANs 104 which are copied to one includes at least one console node 400 and at least one agent 

Lther through a wide area network (WAN) 102. A WAN n<xie 300, but ,t may mclude a plurahty of console nc<ies4W 

102 is a netwodc that spans a relatively large geographical 15 and/or a plurality of agent nodes 300. In general, an agent 

* & node executes software to collect metric data on its 



area. 



. . computer system 150, and a console node 400 executes 

Each LAN 104 composes a plurality of mterconnected J ^ ^ and e ^ 

computer systems and optionaUy one or more other devices: from ^ or ^ ^ A metric fc a 

for example, one or more workstations 110a, one or more measuremeQt of a Ocular tem resourcc . For example, 

personal computers 112a, one or more laptop or notebook ^ ^ ^ cmbodiment , ^ cntcrpr ise management 

computersystemsU^oneormoreservercompute m mctrics ^ M cpiJ> ^ I/Q> fik 

116, and one or more network printers 118. As illustrated in ' processes , kemel) 

FIG. 1, ^^^^P^ 00 ^^ cach ° f ?* P If£ registry,logicalvolumes,andpaging.Eachcomputersystem 

systems 110a, 112a, 114, and 116, and one printer 118. The ^ ^ Enterprise 100 ma y comprise a console node 400, 

l^N 104 may be coupled to o^er computer systems and/or 25 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 

other devices and/or other LANs 104 through a WAN 102. ^ 3Q0 , n the pre f erre d embodiment, server computer 

One or more mainframe computer systems 120 may systems include agent nodes 300, and other computer sys- 

optionally be coupled to the enterprise 100. As shown in tems may also comprise agent nodes 300 as desired, e.g., file 

FIG. 1, the mainframe 120 is coupled to the enterprise 100 ^ ^^crs, print servers, e-mail servers, and internet servers, 

through the WAN 102, but alternatively one or more main- The console no de 400 and agent node 300 are characterized 

frames 120 may be coupled to the enterprise 100 through by an cn d-by-end relationship: a single console node 400 

one or more LANs 104. As shown, the mainframe 120 is may ^ jinked to a single agent node 300, or a single console 

coupled to a storage device or file server 124 and mainframe node may ^ linked to a plurality of agent nodes 300, or 

terminals 122a, 122ft, and 122c. The mainframe terminals ^ a p i urauty 0 f console nodes 400 may be linked to a single 

122a, 122ft, and 122c access data stored in the storage agen t node 300, or a plurality of console nodes 400 may be 

device or file server 124 coupled to or comprised in the linked to a plurality of agent nodes 300. 

mainframe computer system 120. In tne p re f erre< i embodiment, the console node 400 com- 

The enterprise 100 may also comprise one or more prises four user-visible components: a Monitor component 
computer systems which are connected to the enterprise 100 ^ 40^ a Collect graphical user interface (GUI) 404, an Ana- 
through the WAN 102: as illustrated, a workstation 110ft and i yze component 406, and a Predict component 408. All four 
a personal computer 112ft. In other words, the enterprise 100 components 402, 404, 406, and 408 of the console node 400 
may optionally include one or more computer systems arc pre f era bly part of the "BEST/1 FOR DISTRIBUTED 
which are not coupled to the enterprise 100 through a LAN SYSTEMS" software package or "PATROL" version 4.0, all 
104. For example, the enterprise 100 may include computer 45 available from BMC Software, Inc. The agent node 300 
systems which are geographically remote and connected to comprises an Agent 302, one or more data collectors 304, 
the enterprise 100 through the Internet. Universal Data Repository (UDR) history files 210a, and 

The present invention preferably comprises computer Universal Data Format (UDF) history files 212a. In alternate 

programs 160 stored on or accessible to each computer embodiments, the agent node 300 includes either of UDR 

system in the enterprise 100. FIG. 2 illustrates computer 50 210a or UDF 212a, but not both. The Monitor component 

programs 160 and a typical computer system 150. Each 402 allows a user to monitor, in real time, data that is being 

computer system 150 typically comprises components such collected by an Agent 302 and being sent to the Monitor 402. 

as a CPU 152, with an associated memory media. The The Collect GUI 404 is employed to schedule data collec- 

memory media stores program instructions of the computer tion on an agent node 302. The Analyze component 406 

programs 160, wherein the program instructions are execut- 5S takes historical data from a UDR 210a and/or UDF 212a to 

able by the CPU 152. The memory media preferably com- create a model of the enterprise 100. The Predict component 

prises a system memory such as RAM and/or a nonvolatile 408 takes the model from the Analyze component 106 and 

memory such as a hard disk. The computer system 150 allows a user to alter the model by specifying hypothetical 

further comprises a display device such as a monitor 154, an changes to the enterprise 100. Predict 408 can create output 

alphanumeric input device such as a keyboard 156, and 60 in a format which can be understood and displayed by a 

optionally a directional input device such as a mouse 158. Visualizer tool 410. In the preferred embodiment, Visualizer 

The computer system 150 is operable to execute computer 410 is the "BEST/l-VISUALIZER" available from BMC 

programs 160. Software, Inc. 

When the computer programs are executed on one or The Agent 302 controls data collection on a particular 

more computer systems 150, an enterprise management 65 computer system and reports the data in real time to one or 

system 180 is operable to monitor, analyze, and manage the more Monitors 402. In the preferred embodiment, the Agent 

computer programs, processes, and resources of the enter- 302 is the part of the "BEST/1 FOR DISTRIBUTED SYS- 
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TEMS" software package available from BMC Software, interrelated conditions: "IF more than 80% of server CPU is 

Inc. The data collectors 304 collect data from various required by critical production applications, AND the run 

processes and subsystems of the agent node 300. The Agent queue length is greater than six, AND active time on 

302 sends real-time data to the UDR 210a, which is a production disks exceeds 40%." Policies are registered with 

database of historical data in a particular data format. The 5 the Policy Registration Queue 440, from which they are 

UDF 212a is similar to the UDR 210a, but the UDF 212a disseminated to the appropriate Agents 302. An Agent 302 

uses an alternative data format and is written directly by the can execute a plurality of policies simultaneously, 

data collectors 304. FIG. 5 shows an overview of the Agent component 302 of 

FIG 4 shows an overview of the Monitor component 402 the agent node 300 of the enterprise management system 

of the console node 400 of the enterprise management 10 180. In the preferred embodiment, every -agent node 300 has 

system 180. The Monitor 402 comprises a Manager Daemon one Agent 302 ; The Monitor Console 420c k another 

430, one or more Monitor Consoles (as illustrated, 420a and instance of the Monitor Consoles illustrated in FIG. 4 with 

4206), and a Policy Registration Queue 440. Although two reference numbers 420a and 4206. 

Monitor Consoles 420a and 4206 are shown in FIG. 4, the When the user desires to start an Agent 302 and begin 

present invention contemplates that one or more Monitor 15 collecting dato on a particular agent node 300, the use 

Consoles may be executing on any of one or more console operates the Monitor Console 420c to issue an agent start 

^-^Tann request through a Service Daemon 2026. Preferably, the 

nodes 400. Service Daemon 2026 is always executing on the agent node 

In the preferred embodiment, the Monitor Consoles 420a m m onJer {Q intercept mesS ages from one or more Monitor 

and 4206 use a graphical user interface (GUI) for user input Consoles 420c even when the Agent 302 is offline. In the 

and information display. Preferably, the Monitor Consoles 2 o preferred embodiment, the Service Daemon 2026 is largely 

420a and 4206 are capable of sending several different types invisible to the user. The Service Daemon 2026 also 

of requests to an Agent 302, including: alert requests, update intercepts-agent version queries from the Monitor Console 

requests, graph requests, and drilldown requests. An alert 420c. An agent version query is a request for the current 

request specifies one or more thresholds to be checked on a version number of the piece of software that comprises the 

routine basis by the Agent 302 to detect a problem on the 2 s Agent 302. As described above, the Monitor Console 420c 

agent node 300. For example, an alert request might ask the is able to send alert requests, update requests, graph 

Agent 302 to report to the Monitor Console 420a whenever requests, and drilldown requests to the Agent 302. The 

usage of a particular software process exceeds a particular Monitor Console 420c may also send collection requests, 

threshold relative to overall CPU usage on the agent node which are requests for the Agent 302 to begin collecting 

300. An update request is a request for the status of the Agent 30 particular metrics or metric groups on the agent node 300. 

302. For example, the requested status information might When the Agent 302 receives a collect request from the 

include the version number of the Agent 302 or the presence Monitor Console 420c through the Service Daemon 2026, 

of any alarms in the Agent 302. A graph request is a request the Agent 302 initiates the collection through the Collect 

to receive graph data, i.e., data on a metric as routinely Registry Queue (CRQ) 340. The Agent 302 uses the Collect 

collected by the Agent 302, and to receive the data in real 35 Registry Queue 340 to control and schedule data collection, 

time, i.e., whenever it becomes available from the present By helping the Agent 302 know how many collectors 304 

time onward. By obtaining and displaying graph data, the are running and whether the collectors 304 are each the right 

Monitor Console 420a enables the rapid identification and type, the Collect Registry Queue 340 prevents redundant 

communication of potential application and system perfor- collection. Each data collector 310, 312, 314, 316, 318, and 

mance problems. Preferably, the Monitor Console 420a 40 320 is designed to gather one or more metrics for the 

displays graph data in a graphical format A drilldown operating system and/or one or more subsystems. The 

request is a request to receive drilldown data, i.e., data on an present invention contemplates a variety of data collectors 

entire metric group (a set of metrics) as collected by the 304, but for illustrative purposes, the following are shown: 

Agent 302. By obtaining and displaying drilldown data, the system data collector 310 (which collects data from the 

Monitor Console 420a provides the ability to focus, in 45 operating system), ARM data collector 312 (which collects 

real-time, on a specific set of processes, sessions, or users. data from ARMed applications 324), UMX data collector 

Preferably, the Monitor Console 420a displays drilldown 314 (which collects data from user scripts/programs 326), 

data in a tabular format. Oracle data collector 316 (which collects data from an 

Whenever the Agent 302 generates an alarm to indicate a "ORACLE" database management system), Informix data 
troublesome status on the agent node 300, the Manager 50 collector 318 (which collects data from an "INFORMIX" 
Daemon 430 intercepts the alarm and feeds the alarm to one database management system), and Sybase data collector 
or more Monitor Consoles, such as 420a and 4206. 320 (which collects data from a "SYBASE" database man- 
Typically, an alarm is a notification that a particular thresh- agement system). Each of the collectors 310, 312, 314, 316, 
old has been exceeded on a monitored process or subsystem 318, and 320 has an associated input queue 322a, 3226, 
on an agent node 300. The Manager Daemon 430 is capable 55 322c, 322d, 322e, and 322/, respectively. The input queues 
of receiving alarms from a plurality of Agents 302. A 322a, 3226, 322c, 3224 322e, and 322/ store the requested 
Manager Daemon 430 is preferably always running on each metric groups and associated collection intervals for each 
console node 400 so that alarms can be captured even when collector 304. Although a collector 304 typically supports 
the Monitor Consoles 420a and 4206 are offline. multiple metric groups, the collector 304 only collects those 

Each of the Monitor Consoles 420a and 4206 is operable 60 metric groups that are requested. After metric data is 

to issue one or more policies. Apolicy defines a disparate set collected, the data is transferred to a Metric Repository 350 

of metrics to be collected on one or more agent nodes 300. The Metric Repository 350 sits between the Agent 302 and 

In other words, a policy allows a Monitor Console 420a or the collectors 304 and provides fast interprocess comrnum- 

4206 to monitor one or more metrics on one or more agent cation between the Agent process 302 and the collector 

nodes 300 simultaneously. For example, a user could build 65 processes 304. 

and deploy a policy that restricts web browser access on a Metric data from the Metric Repository 350 is efficiently 
plurality of agent nodes 300 with the following set of copied into the Metric Repository Pool 352, where the data 
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is cached by metric group, instance, and collection rate. The ASCII and X terminals, local and remote file servers, 

Metric Repository Pool 352 is located in the memory space independent and dependent transactions, client/server 

of the Agent 302 and is invisible to everything other than the workloads, private and shared memory/transaction, CPU 

Agent 302. By storing collected data for the metric groups priority scheduling, networks of different types, and 

in a single Metric Repository Pool 352 for each Agent 302 5 "ORACLE", "SYBASE", and "INFORMIX" database envi- 

and agent node 300, the enterprise management system 180 ronments. In the preferred embodiment, Analyze 406 takes 

prevents redundant collection: whether one Monitor Con- as input a domain file 466 which identifies the agent nodes 

sole 420c or a plurality of Monitor Consoles such as 420a 300 on the network and the relationship between them, 

through 420c request data collection for a particular metric Analyze 406 also takes as input a data repository in either 

group the data is only collected once. 10 UDF 212c or UDR 210c format, wherein the data repository 

In the preferred embodiment, the Collect Registry Queue 212c or 210c is a set of metric groups collected from one or 

340, Metric Repository 350, Metric Repository Pool 352, more agent nodes 300. 

input queues 322a, 322fc, 322c, 3224, 322e, and 322f, and The Analyze user then can either use a default workload 
Universal Data Repository (UDR) history files 210a, 210f>, specification (.an) 464 or create his or her own, either with 
210c, and 210d comprise a data structure called a base queue 15 the supplied graphical user interface (GUI) 460 or with a 
or BASEQ. A BASEQ is a contiguous relocatable heap of standard text editor 461. A workload specification 464 
memory: in other words, the BASEQ provides random includes a user name, a process name, and other information, 
allocation of data in a contiguous block of storage. The Aworkload is a useful grouping of key performance metrics. 
BASEQ provides fast interprocess communication with For example, the user might classify a plurality of Oracle- 
locking synchronization between the consumer of data and 2 o related processes as an "Oracle" workload, a plurality of 
the provider of data. The BASEQ can be stored in different other processes as a "payroll" workload, and the remainder 
types of memory, such as volatile memory like RAM or as a "miscellaneous" workload. From this classification data, 
nonvolatile memory like a hard disk. In the preferred the Analyze engine 406 creates an Analyze GUI file 462 
embodiment, the BASEQ is implemented as a base class in which contains a list of processes captured within the 
an object-oriented programming environment. In this 25 analysis interval. The Analyze GUI file 462 is then passed to 
embodiment, specialized variants of the BASEQ are imple- the Analyze GUI 460. 

mented as derived classes which inherit the properties of the Using the Analyze GUI file 462, the domain file 466, and 

base class. For example, UDR 210a, 2106, 210c, and 210d the UDF 212c or UDR 210c data repository, Analyze 406 

are implemented with a derived class which is located on a can create several forms of output. First, Analyze 406 can 

file on disk, while Metric Repository 350 is implemented 30 create a model file 468a. The model file 468a is a model of 

with a derived class which is located in a shared memory the workload data as contained in UDF 212c or UDR 210c 

segment. and as classified by the user through the Analyze GUI 460 

In the preferred embodiment, the enterprise management and/or standard text editor 461. Second, Analyze 406 can 

system 180 provides for the storage of historical metric data create reports 472a, which comprise the results of user- 

as well as the monitoring of real-time metric data. Therefore, 3s specified queries concerning workload characteristics. For 

in addition to passing the metric data to the Monitor Console example, one instance of reports 472a could be a list of the 

420c, the Agent may also send the metric data to a Remote top ten workloads sorted by total CPU usage. Third, Analyze 

Repository 360 for storage. The Remote Repository 360 is 406 can create a Visualizer file 470a, wherein the Visualizer 

located on the agent node 300, and each agent node 300 may file 470a is a description of the characteristics of the 

have its own Remote Repository 360. The Remote Reposi- 40 enterprise 100 as determined by the collected metrics and 

tory comprises a database in the Universal Data Repository the user input. The Visualizer file 470a can be read and 

(UDR) format 2106 and/or a database in the Universal Data utilized by the Visualizer tool 410. In the preferred 

Format (UDF) format 212b. The UDF 2126 is an alternative embodiment, Visualizer 410 is the "BEST/1 -VISUALIZER" 

data format to the UDR 2106 and is used primarily by older available from BMC Software, Inc. With Visualizer 410, 

ones of the collectors 304. The UDR format 2106 is multi- 45 performance statistics and workloads can be graphed, 

node: it can store data from multiple sources in one place. compared, drilled down, and visually analyzed to pinpoint 

UDR 2106 is also multi-rate: it can store data at a plurality hot spots or trends to assist in resource management, system 

of levels of varying granularity by sending data at each tuning, and configuration changes. Visualizer 410 preferably 

successive level through an intelligent summarization pro- includes functionality known as MASF (Multivariate Adap- 

cess according to the present invention. Historical data can 50 tive Statistical Filtering). Using standard deviation 

also be stored in a Central Repository 440 on the console techniques, MASF continually interprets performance data 

node 400. A Service Daemon 202a controls the data transfer and calculates normalcy. MASF graphs are thus used to 

from the Remote Repository 360 to the Central Repository discover true performance anomalies that deviate from nor- 

440. In the preferred embodiment, the Central Repository mal performance behavior. In addition to creating Visualizer 

440 comprises a UDR 210d. 55 file 470a and reports 472a, Analyze 406 also generates 

FIG. 6 illustrates an overview of the Analyze component Model files 468a for performance prediction of the system 
406 of the console node 400 of the enterprise management within an enterprise computing environment 100. 
system 180. In the preferred embodiment, Analyze 406 FIG. 7 shows an overview of the Predict component 408 
comprises the "ANALYZE" portion of the "BEST/1 FOR of the console node 400 of the enterprise management 
DISTRIBUTED SYSTEMS" software package available 60 system 180. In the preferred embodiment, Predict 408 
from BMC Software, Inc. Essentially, Analyze 406 takes the comprises the "BEST/1 -PREDICT" component of the 
data collected by one or more Agents 302 and creates a "BEST/1 FOR DISTRIBUTED SYSTEMS" software pack- 
model of one or more computer systems and the processes age available from BMC Software, Inc. Predict 408 is a 
that run on those computer systems. In the preferred planning tool which forecasts the impact of hypothetical 
embodiment, Analyze 106 can model multi-vendor 65 changes on elements of the enterprise 100 such as disparate 
environments, system memory, multiple processors, disk hardware, software, applications, and databases. Predict 408 
drives, logical volumes, RAID devices, load balancing, takes the workload data from a Model File 468c, such as the 
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Model File 468a generated by Analyze 406, and computes 
performance statistics such as workload response times, 
utilization, and throughputs at CPUs, disks, networks, and 
other elements of the enterprise computing environment 
100. Thus, Predict 408 constructs a baseline model from 
collected data that represents the essence of the system 
under management. The user can also operate Predict 408 to 
construct the baseline model from pre-built model 
components, or from a combination of collected data and 
pre-built components. Preferably, Predict 408 uses a graphi- 
cal user interface (GUI) for user input and information 
display. 

After the baseline model has been constructed, the user 
can modify the baseline model by specifying configuration 
corrections, configuration changes, and/or growth scenarios. 
With Predict 408, the user can change one or more attributes 
of any model, creating "what if?" or hypothetical scenarios. 
By using methods, modeling techniques, and statistical 
formulas taken from queuing theory, Predict 408 accurately 
determines the impact of these workload and configuration 
changes on performance and response time. As one of the 
results of "what if?" computation, the changes to the base- 
line are displayed as unitless, numerical response time 
values relative to the baseline value of one. In the preferred 
embodiment, response times are broken down into four key 
components: CPU service time and wait time, I/O service 
time and wait time, network service time and wait time, and 
wait time for transactions running on external systems. 
Using the four key components, Predict 408 also preferably 
calculates other critical performance metrics such as 
throughput rates, CPU queue lengths, disk queue lengths, 
paging rates, and the amount of memory required to elimi- 
nate excessive paging. 

Predict 408 preferably includes a multivendor hardware 
table 469, wherein the table includes the hardware specifi- 
cations that Predict 408 uses to calculate the performance of 
hypothetical changes to the enterprise 100. Therefore, 
changes to CPU, memory, I/O, priorities, transaction rates, 
and other attributes can be evaluated across a plurality of 
heterogeneous computer systems 150. Furthermore, in mod- 
eling the configuration and workload changes across mul- 
tiple systems, Predict 408 automatically calculates interac- 
tion and interference between systems. Predict 408 also 
preferably provides scenario planning, or modeling incre- 
mental growth over time, in order to determine the life 
expectancy of computing resources and the point at which 
resources should be upgraded to ensure that performance 
remains at an acceptable level. In the various ways set forth 
above, Predict 408 thus permits a user to plan for the future 
by "test driving" both actual and alternative or hypothetical 
configurations of the enterprise 100. 

Like Analyze 406, Predict 408 can generate reports 4726, 
a Visualizer file 4706, and a model file 4686. The model file 
4686 can be modified and passed back to Predict 408 for 
additional modeling. 

The UDR data format 210a, 2106, 210c, and 210d 
includes automatic data summarization by data type and/or 
includes summarization with a plurality of levels of granu- 
larity. Summarization operates on two or more data points of 
a particular metric and creates a smaller, summarized ver- 
sion of the metric data by applying different summarization 
rules to different data types. Summarization can operate both 
on raw, unsummarized data and on data that has previously 
been summarized one or more times. With each successive 
summarization, data becomes smaller and coarser in granu- 
larity. In the preferred embodiment, the level of summari- 
zation corresponds to the age of the data. The UDR format 
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210a through 210d thus permits the storage of metric data 
representing a longer period of time than could be main- 
tained without summarization or without a plurality of levels 
of granularity. 

Preferably, all of the metrics can be classified as one of a 
limited number of key data types. Examples of data types 
include, but are not limited to, a counter, a gauge, or a string. 
A gauge is a number that can go up or down from data point 
to data point. For example, the speed of an automobile or the 
utilization percentage of a CPU would be measured by a 
gauge. A counter is a number that is monotonically increas- 
ing from one data point to the next: it can only go up, never 
down. For example, the odometer in an automobile, i.e., the 
indicator of total distance traveled, or the total number of 
15 disk accesses over the lifetime of a disk would be measured 
by a counter. A string is a series of characters which are 
manipulated as a group, as is well known in the art. 
Furthermore, the key data types may have additional 
variants, such as a clock, which is a form of counter 
representing elapsed time. Thus, each of the metrics has a 
semantic, i.e., a meaning, attached to it. The summarization 
method functions more intelligently by applying different 
summarization rules according to the semantics of the data 
type of each metric. 

FIG. 8a is a flowchart showing an overview of the 
semantically correct nature of the summarization of raw 
metric data. In step 602 a series of data points are collected 
for a particular metric. In step 604 the data is received by the 
UDR. In step 606 the UDR determines the data type of the 
data. In step 608 the UDR summarizes the data according to 
the determined data type. 

FIG. 86 is a more detailed flowchart illustrating the 
semantically correct nature of the summarization system and 
method. The data types shown in FIG. 86 are merely 
indicative of the major data types as described above; the 
summarization system and method contemplates additional 
data types not included in FIG. 86, each data type with its 
own semantic and associated summarization rule. The steps 
of FIGS. 8a and 86 are applied to a set of data points 
belonging to a particular metric, Le., a particular perfor- 
mance measurement, which are to be combined into a single, 
summarized data structure. FIGS. 8a and 86 may occur for 
a plurality of metrics and a plurality of sets of data points for 
each metric. 

Each raw data point has an associated timestamp which is 
generated at the time of collection. Regardless of the data 
type, during summarization the first and last timestamps 
over the summarization interval are maintained in the sum- 
marized data structure. In step 620 the summarization 
method uses these timestamps to maintain process state 
changes: the starting time, if known, and the ending time, if 
known, for the process associated with this metric. Step 620 
thus maintains process state changes throughout the levels of 
summarization, so that a process is not averaged out of 
existence or otherwise lost when the summarization rules are 
applied. 

In step 622 the UDR determines the data type of the 
metric data. Next, the UDR applies a summarization rule, 
depending upon the data type determined in step 622. If the 
data type is a counter, then in step 624 the method applies 
a summarization rule which keeps the starting value, the 
ending value, and the number of data points. If the metric is 
a gauge, then in step 626 the method applies a summariza- 
tion rule which keeps the average of the data points and the 
number of data points. If the metric is a string, then in step 
628 the method applies a summarization rule which keeps 
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the first string value over the summarization interval. In step 
630 the method determines whether this metric is a clock. If 
the metric is a clock, then in step 618 the method applies a 
summarization rule which keeps the starting value, the 
ending value, and the frequency of the clock. 

The system and method of the present invention contem- 
plates additional data types not illustrated in FIG. Sb. The 
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following table lists data types in the preferred embodiment, 
along with the raw format, summarization rule, and sum- 
marized format for each data type. Regardless of data type, 
the beginning and ending timestamp over the interval and 
the number of samples or data points are also preferably 
stored; therefore, these elements are not included in the 
"Summarization Rule" column of the table. 



Data Type 



Raw Format 



Summarization Rule Summarized Format 



UDFChar 
UDFVChar 



UDFIdlnt 
UDFIdUint 
UDFUtime 
UDFTJtimeVal 

UDFIdInl8 
UDFFloat 

UDFInt4 

UDFUint4 

UDFUinia 

UDFCount 

UDFCountS 

UDFIntTime 

UDFTuneVal 

UDFTuneTic 



N byte string 

- 4 byte integer (size) 

- 4 byte integer (offset) 

- variable length string 
4 byte signed integer 

4 byte unsigned integer 
4 byte integer (seconds) 
4 byte integer (seconds) 
4 byte integer (10"* sec) 
8 byte integer 
4 byte signed integer 
4 byte integer (10 -0 ) 
4 byte signed integer 

4 byte unsigned integer 

3 byte signed integer 

8 byte unsigned integer 

4 byte integer 
8 byte integer 

4 byte integer (seconds) 

4 byte integer (seconds) 
4 byte integer (10 - * stc) 

4 byte integer (tics) 

4 byte integer (10"* tics) 



First string 
First string 



Last value 
Last value 
Last value 
Last value 

Last value 
Average 

Average 

Average 

Average 

First, last values 
First, last values 
First, latt values 
First, last values 

First, last values 



UDFTUneMicro 4 byte integer (usee) First, last values 

4 byte integer (10~* usees) 



UDFRatioUint4 4 byte integer (numerator) Average 

4 byte integer (denominator) 
UDFRatioCount 4 byte integer (numerator) First, last values 

4 byte integer (denominator) 



UDFAvgTimeS 8 byte integer (num) (rime) First, last values 
4 byte integer (den) (ops) 



Same as raw 
Same as raw 



Same as raw 
Same as raw 
Same as raw 
Same as raw 

Same as raw 
Same as raw 



UDFAvgCount8 8 byte integer (num) 

4 byte integer (den) (ops) 



First, last values 



4 byte integer (whole part) 

4 byte integer (fractional part 10"°) 

4 byte integer (whole part) 

4 byte integer (fractional part 10" 9 ) 

8 byte integer (whole part) 

4 byte integer (fractional part 10"^ - 

8 byte integer (whole part) 

4 byte integer (fractions! fiari iO~°) 

4 byte tt-sgcr (rir«* value) 

4 K'.-c integer (last value) 

n byte integer (first value) 

2 byte integer (last value) 

4 byte integer (first value) 

4 byte integer (last value) 

4 byte integer (seconds) (first) 

4 byte integer (10~° sec) 

4 byte integer (seconds) (last) 

4 byte integer (10^ sec) 

4 byte integer (tics) (first) 

4 byte integer (10"* tics) 

4 byte integer (tics) (last) 

4 byte integer (10"* tics) 

4 byte integer (usee) (first) 

4 byte integer (10"* usees) 

4 byte integer (usee) (last) 

4 byte integer (10"* usees) 

4 byte unsigned integer 

4 byte unsigned integer (10" 9 ) 

4 byte integer (numerator) (first); 

4 byte integer (denominator) (first) 

4 byte integer (numerator) (last) 

4 byte integer (aenominator) (last) 

8 byte integer (num) (time) (first) 

4 byte integer (den) (ops) (first) 

8 byte integer (num) (time) (last) 

4 byte integer (den) (ops) (last) 

8 byte integer (num) (first) 

4 byte integer (den) (ops) (first) 

8 byte integer (num) (last) 

4 byte integer (den) (ops) (first) 



As illustrated in FIG. 11, summarization preferably occurs 
in two types of situations: to satisfy a one-time collect 
request, and to store metric history on a routine basis. A 

fi0 collect request is initiated by a module on a console node 
400, such as Analyze 406 or Predict 408. The collect request 
specifies three values: a collection rate, i.e., how often the 
metric data is to be collected from the agent node 300; a 
summarization or spill interval, i.e., how often the raw spills 
are to be summarized; and a collection interval, i.c., the total 

65 period of time of the data collection. The number of raw 
spills that will be summarized into a single summarized spill 
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equals the spill interval divided by the sample rate. For data file 520, and one summarized data file 522a tough 

example, if the request is to sample data every 10 seconds 522/1 for each Summarize Engine 502a through 502*. The 

and to summarize data every 15 minutes, then each sum- Summarize Engines 502a through 502/1 may comprise the 

marized spill will comprise 90 data points, i.e., 900 seconds same software program being executed a plurality of times, 

divided by 10 seconds. The number of summarized spills 5 The Summarization Method 500 of FIG. 12 comprises each 

that comprise the summarized file sent back to the request- of the Summarize Engines 502a through 502/f as shown in 

ing console node 400 equals the collection interval divided FIG. 11. 

by the spill interval. For example, if the request is for 24 la step 702 of FIG. 10a, for historical summarization as 

hours' worth of collection with data to be summarized every for a collect request, a sample of raw metric data gets 

15 minutes, then there will be 96 summarized spills, i.e., 1Q collected at the specified sample rate. In step 704 the sample 

1440 minutes divided by 15 minutes, sent back to the is written to the Metric Repository 704. In step 706 the 

requesting console node 400 at the end of the 24 hour sample is cached in the Metric Repository Pool 352 By 

collectioT interval. collecting the data only once and by using the Metric 

FIG. 9 is a flowchart illustrating the steps in the summa- Repository Pool 352 to make the same metric data available 

rization that results from a collect request. FIG. 11 is a block 15 to all consumers, the Agent 302 prevents redundant collec- 

diagram illustrating the relationship between the elements non - 

set forth in FIG. 9. In step 650 of FIG. 9, a data collector 304 Step 708 is an invocation of a recursive method A, as 

collects a new sample, i.e., a new data point, at the specified shown in FIG. 106, for the raw data file 520 and the newly 

collection rate. In step 652 the collected metric sample is collected sample. Method A is shown as a fonction or 

transferred from the data collector 304 to the Metric Reposi- 20 method which takes as parameters a filename File and a 

tory 350. As described above, the Metric Repository 350 metric data point "Sample Method A may be repeated a 

allows for interprocess communication between the data plurality of times and may invoke itself a plurality of times, 

collectors 304 and the Metric Repository Pool 352 of the Although method A is shown as a recursive method for ease 

Agent 302. In the preferred embodiment, the Metric Reposi- of illustration, method A could alternately be an iterative 

tory 350 is implemented as a BASEQ stored in a shared 25 method. 

memory segment. In step 654 the sample is copied from the In step 720 the method determines whether File is full, 

Metric Repository 350 to the Metric Repository Pool 352. i.e., whether File is equal to a specified maximum size N F ^. 

The Metric Repository Pool 352 is preferably implemented The user can configure the maximum size of the data file at 

"as a BASEQ contained within the memory space of the each level of summarization, and the user can configure the 

Agent 302, and consequently the copying of metric samples 30 number of levels of summarization. For example, in FIG. 12 

from the Metric Repository 350 to the Metric Repository there are three data files: one raw file 510 and two summa- 

Pool 352 is very fast. rized files 512 and 514. 

In step 656 the new sample is placed in a queue, prefer- Back to step 720 of FIG. 10ft, if File is not full, i.e., if File 

ably in the Metric Repository Pool 352, but in an alternate is less than its specified maximum size N^, then the 

embodiment the new sample is placed in a queue in a 35 method adds Sample to File in step 730 and then returns to 

Summarize Engine 502a. In step 658 the method determines the point at which method A was invoked, 

whether the summarization interval, i.e., spill interval, has If File is full, however, in step 722 the method determines 

expired. If the summarization interval has not expired, then whether File is the coarsest file. The coarsest file is the 

the method proceeds to step 664. If the summarization ultimate, most summarized level of the one or more levels 

interval has expired, then it is time to summarize all the 40 of granularity. If File is the coarsest file, then the method 

queued samples. In step 660 the Summarize Engine 502a proceeds to step 728, where the oldest M Fae samples are 

summarizes the queued samples as described with reference removed from File and thrown away to make space for the 

to FIG. 8 and then writes the resulting summarized data new Sample. Then in step 730, the method adds Sample to 

structure to a summarized data file 522a. Each summarized File and returns to the point at which method A was invoked, 

data structure comprises the information from at least two 45 If File is not the coarsest file, then the method shifts M Fi/tf 

raw data points or from at least two previously summarized samples to the file at the next level of granularity to make 

data structures. In step 662 the method clears the samples spa ce for the new Sample in File. In step 724 the method 

from the queue and resets the summarization interval to the summarizes the oldest M^ samples from File as described 

beginning. with reference to FIG. 8. The result is coarser-sample, which 

In step 664, which occurs whether or not the summari- 50 is a summary of the M^ samples from File. In step 726, 

zation interval has expired, the method determines whether method A is invoked with parameters of next-coarser-file 

the collection interval has expired. If the collection interval and coarser-sample as generated in step 724. This invocation 

has not expired, then the method gpes back to step 650 to in step 726 will add coarser-sample to next-coarser-file, 

collect another sample. If the collection interval has expired, which is the next level of summarization. Because method 

then it is time to end collection and send the results of the 55 A is recursive, the invocation in step 726 may also summa- 

collect request back to the requesting console node 400, so rize and shift samples from next-coarser-file to the level 

the method proceeds to step 668. In step 668 any unsum- beyond next-coarser-file, and so on, until there is room in 

marized samples and incomplete spills are flushed to the next-coarser-file for coarser-sample and in the levels beyond 

summarized file 522a. In step 670 the summarized file 522a for the even coarser summarized samples. Although recur- 

is transferred to the requesting console node 400. 60 sion is well known in the art, this process will be more 

The method also provides for the summarization and intuitively illustrated with specific examples below. After 

storage of historical metric data at a plurality of levels of the method returns from its invocation of method A in step 

varying granularity. FIGS. 10a and 10b show a flowchart of 726, in step 728 the method removes the oldest samples 

historical summarization, and FIGS. 11 and 12 show block from File since they have been shifted to the next level of 

diagrams illustrating the key components of the method. As 65 granularity. With storage space in File thus freed up, in step 

shown in FIG. 11, the UDR format 210e comprises a 730 Sample can be added to File, and then the method can 

plurality of Summarize Engines 502a through 502*, a raw return whence it was invoked. 
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The block diagrams shown in FIGS. 11 and 12 further take up less disk space than at the previous summarization 

illustrate summarization with multiple levels of granularity. level. In other words, at each successive summarization 

In FIG. 11, each raw data point is written to a raw data file level, a single summarized data structure represents a longer 

520. When the raw file 520 fills up, i.e., becomes equal to its period of time than a data point or summarized data structure 

specified maximum size, the oldest data points in the raw file 5 a t th e previous summarization level. In the preferred 

520 are fed into the Level-1 Summarization Engine 5026. embodiment, therefore, the degree of coarseness of the data 

When the configured number of data points are summarized increases with the age of the data, 
in the Level-1 Summarization Engine 5026 into a single 

summarized data structure and then deleted from the raw file file Format of the Universal Data Repository 

520, the summarized data structure gets written to the 10 . 

summarized file 5226. When the Level-1 summarized file n FIG. 13 flustrates the format of me Universal Data 

5226 is full, i.e., equal to its specified maximum size, the ^ m 0De * *° ? leVd ' 

oldest summarized data structures in the Level-1 file 5226 ™R composes one ormore nodes 530. Each node repre- 

are fed to the next level Summarization Engine and deleted **ts an agent node 300 Each of the nod<* 530 fiirther 

from the Level-1 file 5226. The process continues until the 15 comprises one or more instances 540 Each of the instances 

summarized and re-summarized data structures reach the 540 comprises a series of data files for one or more ^metric 

final, Level-N Summarization Engine 502/1. When the 8™ps. examp e as lUustrated m FIG 13, the first 

Level-N summarized file 522/1 is full, i.e., equal to its stance comprises n metric groups (MGs^Each metnc 

specified maximum size, the oldest data structures from the S™P " * e first ms ^f represented by a jngb ^rate data 

Level-N file 522/t are discarded. The number of summari- 20 ®*> * ^™ ratc data filc > a low rate mc - 

zation levels and the file size of each level are user-specified. FIG. 14 illustrates the format of a UDR data file in one 

FIG 12 further illustrates a specific instance of summa- embodiment. A UDR raw data file comprises a file header 

rization with three levels of granularity. Once again, 6«2 and a UDR header 616 followed by raw data spUls. A 

although FIG. 12 shows three levels of granularity for UDR summarized data file comprises a file header 602 and 

illustrative purposes, the present invention contemplates any 25 a UDR header 616 followed by summarized data spills. As 

number of levels, as configured by the user. The data shown, a file header 602 comprises a file size 604, a magic 

collectors 304 provide data to the Agent 302 in a raw format. number 606, and a state 608. The magic number 606 is used 

The Agent 302 writes these raw data points to a High Data to validate file type and to determine the byte order of the 

Rate FIFO File 510. This file 510 is of the finest granularity. contents. The byte order indicates whether the contents are 

When High Data Rate FIFO File 510 fills up, i.e., becomes 30 big-endian or littlenendian, attributes that are well known in 

equal to its specified maximum size N„ the oldest M 1 data the art. The state 608 indicates whether the file was closed 

points from the file 510 are summarized with the Summa- properly and could be used to detect a potentially corrupted 

rization Method 500 into a single summarized data structure file. Hie file size 604 could be used to compare to actual file 

and deleted from the file 510. The summarized data structure size to detect an incomplete or corrupted file, 

is added to a Medium Data Rate FIFO File 512. When the 35 As shown, a UDR header 616 comprises a pedigree 612, 

Medium Data Rate FIFO File 512 is full, i.e., is equal to its a metric table 610, and a speed table 614. The pedigree 612 

specified maximum size N 2 , the oldest M 2 data structures comprises information that allows an object to describe its 

from the file 512 are again summarized with the Summari- origins. The pedigree 612 includes the format type (raw or 

zation Method 500 into a single summarized data structure summarized) 620, the sample interval 622, the metric group 

and deleted from the file 512. Again, the newly summarized 40 name 624, the instance name 626, the identity of the agent 

data structure is placed into Low Data Rate FIFO File 514. node 300 of origin 628, the platform type 630 and operating 

This file 514 is of the coarsest granularity. When the Low system name 632 and version 634 of the agent node 300 of 

Data Rate FIFO File 514 is full, i.e., is equal to its specified origin, the version number 636 of the Agent 302 software on 

maximum size N 3 , the oldest M 3 samples are discarded. the agent node 300 of origin, the UDR version 638, and the 

Sets of data points may be continually gathered from one 4s time zone 640 of the agent node 300 of origin. The metric 

or more data collectors 304 on one or more Agents 302 over table 610 includes information about the form of the data 

a period of time and summarized on a continual basis over such as the names of data items, their size, their data type, 

a period of time. In other words, as new raw data points are and their units. The metric table 610 is therefore meta-data 

continually added to the High Data Rate FIFO File 510, that allows an application to present information about the 

older data points may be summarized and moved to the 50 data in an intelligent way. With the pedigree 612 and metric 

Medium Data Rate FIFO File 512 and then to the Low Data table 610, UDR data files are self-describing. Therefore, the 

Rate FIFO File 514 repetitively. Thus, summarization may UDR data format is extensible to include data types that are 

take place a plurality of times in sequence to generate not yet collected by any existing data collectors 304. In other 

summarized data structures, coarser summarized data words, because of the flexibility of the UDR data file format, 

structures, and further coarser summarized data structures. 55 an application written today would be able to read these 

The data points have timestamps as described above, and the yet-to-be-created data types. 

data points and summarized data structures are preferably The speed table 614 is an index into the data blocks 618. 

ordered by time of collection. Therefore, at any given point The speed table 614 allows the UDR to quickly locate data 

in time, each data file includes a current oldest set of data blocks 618 based on a given time range. Preferably, the data 

and a current youngest set of data. The gathering and the 60 blocks 618 are implemented with a BASEQ. Each data 

summarization may take place on the same computer block, i.e., data spill, is a snapshot of an entire metric group 

system, or they make take place on different computer for a particular time interval. A raw data block comprises a 

systems. spill header and a plurality of raw data records. These UDR 

At each successive summarization level, the data are older raw data blocks are in the same format as the raw collect 

than the data at the previous summarization level. With each 65 spills which are queued in the Metric Repository 350 and 

successive summarization level, the data representing a Metric Repository Pool 352. A summarized data block 

given time interval are coarser in granularity and preferably comprises a summarized spill header and a plurality of 
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summarized data records. A summarized data block differs 
from a raw data block by the format of the records contained. 

FIG. 15 illustrates the structure of data and header records 
in UDR in one embodiment. As shown in FIG. 15, a 
summarized header record 702 comprises a header block 5 
and summarized header metrics (as described in the metric 
description table). The header block comprises a header 
record offset (a 4-byte integer) and the number of raw spills 
(a 4-byte integer). The number of raw spills refers to the 
number of spills that were summarized. The summarized 10 
header metrics are each of the header metrics in summarized 
format. 

As shown in FIG. 15, a summarized data record 704 
comprises a header block, a summarized header record as 
described above, and summarized data metrics. The header ^ 
block, which contains the offsets within the record to the 
header and data, comprises a record offset for the summa- 
rized header record (a 4-byte integer) and a record offset for 
the summarized data metrics (a 4-byte integer). A data 
record may not have existed over the entire summarization 
interval. For example, a process may have started and ended 
within the interval. For this reason, there needs to be a 
summarized header record within each summarized data 
record that will reflect the times the record (process) existed. 
It is identical in format to the summarized header record for 

25 

the spill, but will only contain summarized header metrics 
for those spills that the record existed. The summarized data 
metrics is each of the data metrics in summarized format. 

FIG. 16 illustrates the processing flow from Metric 
Repository (Agent) records to Data Repository (UDR) 3Q 
records in one embodiment. 

Although,the system and method of the present invention 
have been described in connection with several 
embodiments, the invention is not intended to be limited to 
the specific forms set forth herein, but on the contrary, it is 35 
intended to cover such alternatives, modifications, and 
equivalents, as can be reasonably included within the spirit 
and scope of the invention as defined by the appended 
claims. 

What is claimed is: ^ 

1. A method for managing the performance of an 
enterprise, wherein the enterprise comprises one or more 
computer systems, the method comprising: 

receiving a set of data points from the one or more 
computer systems, wherein the set of data points com- 4S 
prises a series of measurements of one or more system 
resources of the one or more computer systems over a 
period of time; 
summarizing the set of data points, wherein the summa- 
rizing comprises: 50 
determining a data type of the set of data points; and 
creating a summarized data structure including a plu- 
rality of data structures; 
applying a summarization rule on the set of data points 

according to the data type; and 55 
storing data from said application of the summarization 
rule to a first data structure of the plurality of data 
structures. 

2. The method of claim 1, 

wherein the data type is a counter, wherein the counter is 60 
a measurement which is capable of increasing or stay- 
ing the same and not capable of decreasing from one 
data point to a next data point 

3. The method of claim 2, 

wherein the applying the summarization rule comprises 65 
determining a starting value, an ending value, and a 
total number of data points for the set of data points; 
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wherein the summarized data structure comprises the 
starting value, the ending value, and the total number of 
data points. 

4. The method of claim 1, 

wherein the data type is a gauge, wherein the gauge is a 
measurement which is capable of increasing or decreas- 
ing from one data point to a next data point. 

5. The method of claim 4, 

wherein the applying the summarization rule comprises 
determining an average value of all the data points and 
a total number of data points for the set of data points; 

wherein the summarized data structure comprises the 
average and the total number of data points. 

6. The method of claim 1, 

wherein the data type is a string, wherein the string is a 
series of characters which can be manipulated as a 
group. 

7. The method of claim 6, 

wherein the applying the summarization rule comprises 
determining a first string value and a total number of 
data points for the set of data points; 

wherein the summarized data structure comprises the first 
string value and the total number of data points. 

8. The method of claim 1, 

wherein the data type is a clock, wherein the clock is a 
measurement of elapsed time which is capable of 
increasing or staying the same and not capable of 
decreasing from one data point to a next data point. 

9. The method of claim 8, 

wherein the applying the summarization rule comprises 
determining a starting value, an ending value, and a 
frequency of the clock for the set of data points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the frequency. 

10. The method of claim 1, 

wherein each of the set of data points includes a times- 
tamp indicating a time of collection; 

wherein the summarizing the set of data points further 
comprises determining a first times tamp and a last 
times tamp for the set of data points; 

wherein the summarized data structure includes the first 
timestamp and the last timestamp. 

11. The method of claim 1, 

wherein the set of data points further comprises measure- 
ments of one or more processes of one or more com- 
puter systems over the period of time; 

wherein the summarizing the set of data points further 
comprises determining one or more state changes from 
the set of data points, wherein the state changes com- 
prise a starting time for each process begun within the 
period of time and an ending time for each process 
ended within the period of time; 

wherein the summarized data structure includes the state 
changes. 

12. The method of claim 1, 

wherein the receiving the set of data points from the one 
or more computer systems and the summarizing the set 
of data points are performed for a plurality of sets of 
data points, and wherein the receiving the set of data 
points from the one or more computer systems and the 
summarizing the set of data points are performed a 
plurality of times. 

13. The method of claim 12, 

wherein at least one set of data points comprises a set of 
summarized data structures, wherein the set of sum- 
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marized data structures corresponds to a plurality of 
sets of data points, wherein each of the plurality of sets 
of data points was previously summarized into a sum- 
marized data structure. 

14. The method of claim 1, further comprising: 5 
gathering the set of data points from the one or more 

computer systems, wherein the gathering the set of data 
points from the one or more computer systems occurs 
prior to the receiving the set of data points from the one 
or more computer systems. 10 

15. The method of claim 14, 

wherein the gathering the set of data points from the one 
or more computer systems, the receiving the set of data 
points from the one or more computer systems, and the 
summarizing the set of data points occur on the same 15 
computer system. 

16. The method of claim 14, 

wherein the gathering the set of data points from the one 
or more computer systems and the summarizing the set 2Q 
of data points from the one or more computer systems 
occur on different computer systems. 

17. The method of claim 1, wherein said summarizing 
further comprises: 

applying another summarization rule on at least part of the 25 
data stored in the first data structure according to the 
data type of the first data structure; and 

storing data from said application of the another summa- 
rization rule to a second data structure of the plurality 
of data structures. 30 

18. A system for managing the performance of an 
enterprise, wherein the enterprise comprises one or more 
computer systems, the system comprising: 

a CPU; 

a system memory coupled to the CPU, wherein the system 3S 
memory stores one or more computer programs execut- 
able by the CPU; 
wherein the computer programs are executable to: 
receive a set of data points, wherein the set of data 
points comprises a series of measurements of one or 
more system resources of one or more computer 
systems over a period of time; and 
summarize the set of data points, wherein in summa- 
rizing the set of data points, the computer programs 4S 
are executable to: 

determine a data type of the set of data points; 

create a summarized data structure including a plu- 
rality of data structures; 

apply a summarization rule on the set of data points 5Q 
according to the data type; and 

store data from said application of the summarization 
rule to a first data structure of the plurality of data 
structures, 

19. The system of claim 18, wherein in said summarizing 55 
the set of data points the computer programs are further 
executable to: 

apply another summarization rule on at least part of the 
data stored in the first data structure according to the 
data type of the first data structure; and 60 

store data from said application of the another summari- 
zation rule to a second data structure of the plurality of 
data structures. 

20. The system of claim 18, 

wherein the data type is a gauge, wherein the gauge is a 65 
measurement which is capable of increasing or decreas- 
ing from one data point to a next data point. 
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21. The system of claim 20, 

wherein in applying the summarization rule, the computer 
programs are executable to determine an average value 
of all the data points in the set of data points and a total 
number of data points for the set of data points; 

wherein the summarized data structure comprises the 
average and the total number of data points. 

22. The system of claim 18, 

wherein the data type is a string, wherein the string is a 
series of characters which can be manipulated as a 
group. 

23. The system of claim 22, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a first string 
value and a total number of data points for the set of 
data points; 

wherein the summarized data structure comprises the first 
string value and the total number of data points. 

24. The system of claim 18, 

wherein the data type is a clock, wherein the clock is a 
measurement of elapsed time which is capable of 
increasing or staying the same and not capable of 
decreasing from one data point to a next data point. 

25. The system of claim 24, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a starting value, 
an ending value, and a frequency for the set of data 
points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the frequency. 

26. The system of claim 18, 

wherein each of the set of data points includes a times- 
tamp indicating a time of collection; 

wherein in summarizing the set of data points, the com- 
puter programs are executable to determine a first 
times tamp and a last timestamp for the set of data 
points; 

wherein the summarized data structure includes the first 
timestamp and the last timestamp. 

27. The system of claim 18, 

wherein the set of data points further comprises measure- 
ments of one or more processes of one or more com- 
puter systems over the period of time; 

wherein in summarizing the set of data points, the com- 
puter programs are executable to determine one or 
more state changes from the set of data points, wherein 
the state changes comprise a starting time for each 
process begun within the period of time and an ending 
time for each process terminated within the period of 
time; 

wherein the summarized data structure includes the state 
changes. 

28. The system of claim 18, 

wherein the computer programs are executable to receive 
the set of data points and summarize the set of data 
points for a plurality of sets of data points. 

29. The system of claim 28, 

wherein at least one set of data points comprises a set of 
summarized data structures, wherein the set of sum- 
marized data structures corresponds to a plurality of 
sets of data points, wherein each of the plurality of sets 
of data points was previously summarized into a sum- 
marized data structure. 
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30. The system of claim 18, 

wherein the data type is a counter, wherein the counter is 
a measurement which is capable of increasing or stay- 
ing the same and not capable of decreasing from one 
data point to a next data point, 5 

31. The system of claim 30, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a starting value, 
an ending value, and a total number of data points for 
the set of data points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the total number of 
data points. 

32. A system for managing an enterprise, wherein the J5 
enterprise comprises a plurality of computer systems, the 
system comprising: 

a network comprising a plurality of interconnected com- 
puter systems, wherein each of the plurality of inter- 
connected computer systems includes one or more 2 o 
system resources; 
wherein at least one computer system of the plurality of 
interconnected computer systems is operable to store a 
set of data points received from the plurality of inter- 
connected computer systems, wherein the set of data 25 
points comprises a series of measurements of one or 
more system resources of the plurality of intercon- 
nected computer systems over a period of time; 
wherein the at least one computer system comprises: 
a CPU; 30 
a system memory coupled to the CPU, wherein the 
system memory stores one or more computer pro- 
grams executable by the CPU; 
wherein the computer programs are executable to: 

receive the set of data points; and 35 
summarize the set of data points, wherein in sum- 
marizing the set of data points, the computer 
programs are executable to: 
determine a data type of the set of data points; 
create a summarized data structure including a 40 

plurality of data structures; 
apply a summarization rule on the set of data 

points according to the data type; and 
store data from said application of the summari- 
zation rule to a first data structure of the 45 
plurality of data structures. 

33. The system of claim 32, 

wherein the data type is a gauge, wherein the gauge is a 
measurement which is capable of increasing or decreas- ^ 
ing from one data point to a next data point. 

34. The system of claim 33, 

wherein in applying the summarization rule, the computer 
programs are executable to determine an average value 
of all the data points in the set of data points and a total $5 
number of data points for the set of data points; 

wherein the summarized data structure comprises the 
average and the total number of data points. 

35. The system of claim 32, 

wherein the data type is a string, wherein the string is a 60 
series of characters which can be manipulated as a 
group. 

36. The system of claim 35, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a first string 65 
value and a total number of data points for the set of 
data points; 
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wherein the summarized data structure comprises the first 
string value and the total number of data points. 

37. The system of claim 32, 

wherein the data type is a clock, wherein the clock is a 
measurement of elapsed time which is capable of 
increasing or staying the same and not capable of 
decreasing from one data point to a next data point. 

38. The system of claim 37, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a starting value, 
an ending value, and a frequency for the set of data 
points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the frequency. 

39. The system of claim 32, 

wherein each of the set of data points includes a times- 
tamp indicating a time of collection; 

wherein in summarizing the set of data points, the com- 
puter programs are executable to determine a first 
times tamp and a last timestamp for the set of data 
points; 

wherein the summarized data structure includes the first 
timestamp and the last timestamp. 

40. The system of claim 32, 

wherein the set of data points further comprises measure- 
ments of one or more processes of the one or more 
computer systems over the period of time; 

wherein in summarizing the set of data points, the com- 
puter programs are executable to determine one or 
more state changes from the set of data points, wherein 
the state changes comprise a starting time for each 
process begun within the period of time and an ending 
time for each process terminated within the period of 
time; 

wherein the summarized data structure includes the state 
changes. 

41. The system of claim 32, 

wherein the computer programs are executable to receive 
the set of data points and summarize the set of data 
points for a plurality of sets of data points. 

42. The system of claim 41, 

wherein at least one set of data points comprises a set of 
summarized data structures, wherein the set of sum- 
marized data structures corresponds to a plurality of 
sets of data points, wherein each of the plurality of sets 
of data points was previously summarized into a sum- 
marized data structure. 

43. The system of claim 32, 

wherein at least one computer system of the plurality of 
interconnected computer systems is operable to gather 
the set of data points from itself, wherein the set of data 
points comprises a series of measurements of one or 
more system resources of the plurality of intercon- 
nected computer systems over a period of time. 

44. The system of claim 43, 

wherein at least one computer system that is operable to 
gather the set of data points is the same as at least one 
computer system that is operable to summarize the set 
of data points. 

45. The system of claim 43, 

wherein at least one computer system that is operable to 
gather the set of data points is different from at least one 
computer system that is operable to summarize the set 
of data points. 
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46. The system of claim 32, 

wherein the data type is a counter, wherein the counter is 
a measurement which is capable of increasing or stay- 
ing the same and not capable of decreasing from one 
data point to a next data point 

47. The system of claim 46, 

wherein in applying the summarization rule, the computer 
programs are executable to determine a starting value, 
an ending value, and a total number of data points for 
the set of data points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the total number of 
data points. 

48. The system of claim 32, wherein in said summarizing 
the set of data points the computer programs are further 
executable to: 

apply another summarization rule on at least part of the 
data stored in the first data structure according to the 
data type of the first data structure; and 

store data from said application of the another summari- 
zation rule to a second data structure of the plurality of 
data structures. 

49. A memory medium which stores program instructions 
for managing the performance of an enterprise, wherein the 25 
enterprise comprises one or more computer systems, 
wherein the program instructions are executable to imple- 
ment: 

summarizing a set of data points from the one or more 
computer systems, wherein the set comprises a series of 30 
measurements of one or more system resources of the 
one or more computer systems over a period of time, 
wherein the summarizing comprises: 
determining a data type of the set of data points; 
applying a summarization rule according to the data 

type of the set of data points; and 
creating a summarized data structure corresponding to 

the set of data points. 

50. The memory medium of claim 49, 
wherein the data type is a gauge, wherein the gauge is a 

measurement which is capable of increasing or decreas- 
ing from one data point to a next data point. 

51. The memory medium of claim 49, 
wherein the data type is a string, wherein the string is a 

series of characters which can be manipulated as a 
group. 

52. The memory medium of claim 51, 
wherein the applying the summarization rule comprises 

determining a first string value and a total number of 
data points for the set of data points; 
wherein the summarized data structure comprises the first 
string value and the total number of data points. 

53. The memory medium of claim 49, 
wherein the data type is a clock, wherein the clock is a 

measurement of elapsed time which is capable of 
increasing or staying the same and not capable of 
decreasing from one data point to a next data point. 
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54. The memory medium of claim 53, 

wherein the applying the summarization rule comprises 
determining a starting value, an ending value, and a 
frequency of the clock for the set of data points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the frequency. 

55. The memory medium of claim 49, 

wherein each of the set of data points includes a times- 
tamp indicating a time of collection; 

wherein the summarizing the set of data points further 
comprises determining a first timestamp and a last 
timestamp for the set of data points; 

wherein the summarized data structure includes the first 
timestamp and the last timestamp. 

56. The memory medium of claim 49, 

wherein the set of data points further comprises measure- 
ments of one or more processes of one or more com- 
puter systems over the period of time; 

wherein the summarizing the set of data points further 
comprises determining one or more state changes from 
the set of data points, wherein the state changes com- 
prise a starting time for each process begun within the 
period of time and an ending time for each process 
ended within the period of time; 

wherein the summarized data structure includes the state 
changes. 

57. The memory medium of claim 49, 

wherein the summarizing a set of data points is performed 
a plurality of times for a plurality of sets of data points. 

58. The memory medium of claim 57, 

wherein at least one set of data points comprises a set of 
summarized data structures, wherein the set of sum- 
marized data structures corresponds to a plurality of 
sets of data points, wherein each of the plurality of sets 
of data points was previously summarized into a sum- 
marized data structure. 

59. The memory medium of claim 49, 

wherein the data type is a counter, wherein the counter is 
a measurement which is capable of increasing or stay- 
ing the same and not capable of decreasing from one 
data point to a next data point 

60. The memory medium of claim 59, 

wherein the applying the summarization rule comprises 
determining a starting value, an ending value, and a 
total number of data points for the set of data points; 

wherein the summarized data structure comprises the 
starting value, the ending value, and the total number of 
data points. 

61. The memory medium of claim 50, 

wherein the applying the summarization rule comprises 
determining an average value of all the data points and 
a total number of data points for the set of data points; 

wherein the summarized data structure comprises the 
average and the total number of data points. 
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